Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server

Hi @MathiasBaumgartinger and thanks for your interest in the GitHub docs 👋

I'm afraid we won't be accepting this contribution on this occasion—I'll outline our reasoning below:

• There are a few places where we'd need to make this change, and it requires a more considered approach than only adding the content you've proposed to one article.

• Generally, we take an "opinionated" approach to content where there are multiple possible solutions, and pick one method and stick to it. That's something that we agree with stakeholders internally at time of publication, and once the content is published, unless there's something actually wrong about using that method and that feedback is surfaced, then we won't change it.

For cases like this, where there isn't an immediately straightforward solution, I'd really recommend opening an issue first before taking time to write a PR. That way we can have a discussion first, and everybody involved—most importantly, you—has a better experience.

I will pass on feedback to the content team in question for any future updates they may make to this article.

Thanks again for your interest in the GitHub docs.

Hey there!

I accidentally got caught in the same trap today again. I really cannot understand why you would recommend BFG for a solution that can honestly be solved in a matter so much simpler. For the sake of all other clumsy fellows out there, I would really appreciate you consider exposing this option in your documentation.

@MathiasBaumgartinger Thank you for sharing! Would you be able to raise an issue (instead of a PR) in this repo on this topic? We can then have our SMEs review your proposal and gather their feedback on the best path forward 💛

Hi,

The alternative text suggested here might work great for some users, but it doesn't provide warnings about when it is applicable (only if the history is linear, only if the large files are contained to one branch, and as the instructions are written, only if the large file was only touched in a single commit) which could be very deleterious for other users. See #34950 for more details. Also, as promised there, we do have a pending change that will mention interactive rebase, but with the caveats listed.

Docs team: It's a little